Skip to content

Fix duplicate identity#959

Draft
pblazej wants to merge 2 commits intomainfrom
blaze/duplicate-identity
Draft

Fix duplicate identity#959
pblazej wants to merge 2 commits intomainfrom
blaze/duplicate-identity

Conversation

@pblazej
Copy link
Copy Markdown
Contributor

@pblazej pblazej commented Mar 31, 2026 •
edited
Loading

Resolves #958

After unpublishAll(), the sticky hasPublished flag kept the publisher transport marked as critical. When the idle publisher ICE timed out, this triggered an unnecessary reconnect cycle that escalated from quick to full, connecting without the reconnect flag and causing the server to remove the participant with DUPLICATE_IDENTITY.

Reset hasPublished to false when no track publications with non-nil tracks remain, preventing both the spurious reconnect trigger and unnecessary publisher ICE restarts during any server-initiated reconnect.

@pblazej pblazej mentioned this pull request Mar 31, 2026
Open
@Daltron
Copy link
Copy Markdown

Daltron commented Mar 31, 2026

@pblazej thank you for such a quick fix and solution! I can confirm that this does indeed fix the undesired reconnection issue from happening! However, it appears it introduced a new issue. If the LocalParticipant tries to republish their tracks after they unpublished them, the video and audio tracks are published (According to the delegates) but you can neither see them or hear them on either the local or remote sides.

However, on the RemoteParticipant side, only didPublishTrack is called for the audio track and the new video track never comes through. But like I mentioned, you are unable to hear them.

I can also confirm this was not an issue before this change because as soon as the undesired reconnection took place, we could successfully publish (and see and hear the tracks) again on all devices.

@pblazej
Copy link
Copy Markdown
Contributor Author

pblazej commented Mar 31, 2026

@Daltron let me revisit it, will keep you posted.

@Daltron
Copy link
Copy Markdown

Daltron commented Mar 31, 2026

@pblazej really appreciate it, thank you!

@pblazej
Copy link
Copy Markdown
Contributor Author

pblazej commented Apr 1, 2026

@Daltron I was unable to reproduce this particular regression in an isolated environment (killing ICE, blocking UDP, etc.).

However, I think there's another gap in the logic I tried to fix above ⬆️

It would be great to validate on your side (and provide full logs).

@Daltron
Copy link
Copy Markdown

Daltron commented Apr 1, 2026 •
edited
Loading

@pblazej Unfortunately, the same issue persists to where local tracks can not be published a second time. I've attached logs which are broken down into sections which indicate what is triggered where:

livekit_logs.txt

@pblazej
Copy link
Copy Markdown
Contributor Author

pblazej commented Apr 2, 2026 •
edited
Loading

@Daltron I think I'd need full logs:

/* 10-15 seconds later */

on .debug level.

Preferably from main as well (with the original issue).

@Daltron
Copy link
Copy Markdown

Daltron commented Apr 3, 2026 •
edited
Loading

@pblazej attached are the full logs from the blaze/duplicate-identity branch!
live_logs_full.txt

@pblazej
Copy link
Copy Markdown
Contributor Author

pblazej commented Apr 9, 2026

@Daltron thanks for the full details, I think the root cause is in the transceiver cleanup (workaround)...

Added one more change - let's try to validate it ⬆️ 🤞

@pblazej
Copy link
Copy Markdown
Contributor Author

pblazej commented Apr 15, 2026

@Daltron were you able to check it with the latest release (2.13.0)?

@Daltron
Copy link
Copy Markdown

Daltron commented Apr 15, 2026

@pblazej I have tested both the 2.13.0 release and this branch and nothing has changed unfortunately.

@pblazej
Copy link
Copy Markdown
Contributor Author

pblazej commented Apr 16, 2026

@Daltron are you able to reproduce it locally in a reliable way? Any specific steps?

@Daltron
Copy link
Copy Markdown

Daltron commented Apr 16, 2026

@pblazej I am able to reproduce it 100% of the time locally:

  1. On device A, create a room and start publishing local tracks (video and audio) to it
  2. On device B, subscribe to that room (gives you tracks from Device A)
  3. On device B, start publishing local tracks to that room
  4. On device B, unpublish the local tracks but stay subscribed to device A's room

Two issues:

  1. If you wait about 15 seconds, you will see that we lose device A's tracks on device B's for a split second but the reconnection successfully occurs and we get them back.
  2. If you try to republish device B's local tracks before issue 1 finishes (before you wait 15 seconds and for the reconnect to occur), device A can not see device B's tracks. However if you wait for the reconnection to occur and then try to republish the local tracks, then it works perfectly.

pblazej and others added 2 commits April 22, 2026 13:23
@pblazej @claude
fix(publish): reset hasPublished when all tracks are unpublished (#958)
7bf838d 
After unpublishAll(), the sticky hasPublished flag kept the publisher
transport marked as critical. When the idle publisher ICE timed out,
this triggered an unnecessary reconnect cycle that escalated from quick
to full, connecting without the reconnect flag and causing the server
to remove the participant with DUPLICATE_IDENTITY.

Reset hasPublished to false when no track publications with non-nil
tracks remain, preventing both the spurious reconnect trigger and
unnecessary publisher ICE restarts during any server-initiated
reconnect.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@pblazej @claude
test(publish): add failing republish-after-unpublish regression test
875b271 
Reproduces #958: publish simulcast video (720x1280, 3 layers) + audio,
unpublish all, then republish — only audio reaches the remote side,
video never appears (trackPublications.count → 1 instead of 2).

The test uses the same parameterized V0/V1 pattern as the existing
signaling tests and is expected to fail until the underlying
transceiver reuse issue is fixed.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@pblazej pblazej force-pushed the blaze/duplicate-identity branch from 4ae0adb to 875b271 Compare April 23, 2026 13:36
@github-actions
Copy link
Copy Markdown

github-actions Bot commented Apr 23, 2026

⚠️ This PR does not contain any files in the .changes directory.

@pblazej
Copy link
Copy Markdown
Contributor Author

pblazej commented Apr 28, 2026

@boks1971 I tried to extract something from logs, do you think we can fix the regression server-side?

republish-server-timeline.md

@pblazej
Copy link
Copy Markdown
Contributor Author

pblazej commented Apr 28, 2026

@Daltron to be absolutely sure, could you try reproducing against staging environment e.g. http://meet.staging.livekit.io/ to get server-side logs cc @boks1971

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

Unpublishing local tracks is causing a participant_left and participant_joined cycle

2 participants

@pblazej @Daltron